Social network transaction processing system

ABSTRACT

A system for transferring funds using social network connections. The system sends application programming interface (API) requests to social networks to obtain “friend” information and create accounts into which funds are deposited and which may be retrieved by recipients via hyperlinks in messages provided through social networks. The system may also be used to request funds from social network friends. The system provides benefactor friends fund requests in the form of social network messages, which allow the benefactors to access the system and provide funds to a user via hyperlinks in the messages.

This application is a Divisional application of U.S. Ser. No.12/931,141.

TECHNICAL FIELD

The disclosed embodiments relate generally to financial transactionsand, in particular, to using social networks to execute the transfer offunds.

BACKGROUND

Conventional financial institutions only support financial transactionsfrom one financial institution to another. To limit fraud, thesefinancial institutions require specific information from both theprovider of the funds and the recipient before executing a financialtransaction. Required information typically includes the parties' fullnames, the names of the financial institutions, the parties' accountnumbers and the recipient's ABA routing number. It would be desirablefor one party to send or request money without the requirement that theparty have all of this additional information.

Services like Obopay use mobile telephony devices to transfer fundsbetween parties. When it is desired to transfer funds from one party tothe other, both parties register with a third party provider, such asObopay. At least one of the parties deposits funds into the system froma conventional financial institution. Once funds have been transferred,the party with the funds may transfer all or part of the funds to theother party by accessing the Obopay software, with a mobile device, andentering in the receiver's telephone number to execute the transfer.Once the funds have been transferred, the recipient may access the fundsby accessing the provider software. One drawback associated with suchprior art systems is the requirement that the parties have each createda third party account with a third party provider before the fundstransfer can take place.

Another drawback associated with such prior art systems is therequirement that the party seeking to transfer the funds has access tothe recipient's telephone number. Still another drawback associated withsuch prior art systems is the difficulty associated with putting fundsinto and taking funds out of the system. It would, therefore, bedesirable to provide a system for transferring funds from one party toanother that did not require the registration of both parties before thetransaction, and which did not require having the other party'stelephone number stored prior to the transaction. It would also bedesirable to facilitate the input and output of funds into and out ofthe system.

It is also known in the art to transfer funds from one party to anotherusing alternative information, such as an email address. Paypal is anexample of a financial transaction processing system that allows partiesto transfer funds to one another using only the other party's emailaddress. One drawback associated with such prior art processes is therequirement that both parties preregister with a third party providerand set up accounts with the system prior to transferring funds.

Another drawback is the requirement that the party initiating thetransfer of funds must have the requesting party's email address, priorto initiating the funds transfer. While funds can be transferreddirectly from a Paypal account to a conventional financial institution,it would be desirable to provide a system which did not requirepreregistration and third-party account creation by both parties with aparticular provider. It would also be desirable to provide a system thatdid not require the party transferring funds to have specificinformation about the recipient, such as email address, on hand.

SUMMARY OF THE DISCLOSED SUBJECT MATTER

The present invention includes systems and methods for transferringfunds from one party to the other. A user signs into the system andrequests transfer to a recipient. The system accesses a social networkplatform of which the user and recipient are authorized to communicatewith one another and extracts additional required information regardingthe recipient, such as the recipient's username.

As the user is authorized to send messages via the social networkdirectly to the recipient, the system transfers the desired funds fromthe user's account to an account the system associates with therecipient's social network username. The system then uses theapplication programming interface of the social network to access theuser's profile and send a message to the recipient's social networkprofile, indicating the funds have been transferred and are available tothe recipient. The recipient accesses the system via a hyperlinkprovided in the message sent via the social network. The recipient mayaccess the funds by providing additional identifying information or byauthorizing the system access to the recipient's social network platformprofile. The recipient may then transfer all or part of the funds toanother party in a similar manner, or may transfer the funds from thesystem to vendor or a conventional financial institution.

The features and advantages described in this summary and the followingdetailed description are not all-inclusive. Many additional features andadvantages may be apparent to one of ordinary skill in the art in viewof the drawings, specification and claims presented herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described, by way of example, withreference to the accompanying drawings in which:

FIG. 1 illustrates a block diagram of the system architecture inaccordance with one embodiment;

FIG. 2 illustrates a block diagram of the social network architecture inaccordance with one embodiment;

FIG. 3 illustrates a block diagram of the financial system architecturein accordance with one embodiment;

FIG. 4 illustrates an example display from an application running on anexternal system, the display showing the global transaction historywebpage in accordance with one embodiment;

FIG. 5 illustrates an example display from an application running on anexternal system, the display showing the send money webpage inaccordance with one embodiment;

FIG. 6 illustrates an example display from an application running on anexternal system, the display showing the confirmation webpage inaccordance with one embodiment;

FIG. 7 illustrates an example display from an application running on anexternal system, the display showing the money out transaction webpagein accordance with one embodiment;

FIG. 8 illustrates an example display from an application running on asocial network, the display showing a funds available message inaccordance with one embodiment;

FIG. 9 illustrates an example display from an application running on anexternal system, the display showing the homepage webpage in accordancewith one embodiment;

FIG. 10 illustrates an example display from an application running on anexternal system, the display showing the requests transaction webpage inaccordance with one embodiment;

FIG. 11 illustrates an example display from an application running on anexternal system, the display showing the requested funds webpage inaccordance with one embodiment;

FIG. 12 illustrates an example display from an application running on anexternal system, the display showing the funds out transaction webpagein accordance with one embodiment;

FIG. 13 illustrates an example display from an application running on anexternal system, the display showing the request funds webpage inaccordance with one embodiment; and

FIG. 14 illustrates an example display from an application running on asocial network, the display showing a funds request message inaccordance with one embodiment

DETAILED DESCRIPTION OF THE DRAWINGS

As shown in FIG. 1, a transaction processing system (100) is provided toallow a user (102) to transfer funds (104) to a recipient (106) across anetwork (108). As shown in FIG. 1, the user (102) may use a computingdevice, such as a client device (110) to transfer the funds (104). Theclient device (110) may be of any type known in the art, including, butnot limited to, a desktop, workstation, notebook, netbook, net tablet,mainframe, terminal or any device having the capability of communicatingover a network (108). In an embodiment, the client device (110) isprovided with network access applications known in the art, such as abrowser (112) to facilitate communication over the network (108). Thenetwork (108) may be of any type known in the art, including, but notlimited to, the Internet, a local area network (LAN), a wide-areanetwork (WAN), telephony or any combination thereof. The client device(110) is provided and configured to execute computer executableinstructions that cause the browser (112) to perform the method detailedmore fully below.

The user (102) is also a member of a social network (114). The socialnetwork (114) is preferably Facebook, but may be Twitter®, Foursquare,LinkedIn or any suitable social network known in the art. Generally, thesocial network (114) provides its members (116) with a platform tointeract with other members (116) of the social network (114). Themembers (116) may “friend” one another, or otherwise make internalconnections, by authorizing (118) other members (116) to accessinformation associated with their social network profiles. Members (116)may add connections (118) to other members (116) individually, or mayadd groups of members (116) associated with a particular organization,hobby or group as allowed by the social network (114). Alternatively,the social network (114) may automatically add connections (118) betweenmembers (116) given various members' similar interests in variousactivities or past connections, such as work history or priormatriculation.

Most of the connections (118) are “two-way” connections (120), whereboth parties are allowed to directly communicate with one another. Someconnections (118) may be one-way connections (122), where a user profile(124) is authorized to communicate directly with a friend profile (126),but the friend profile (126) is not authorized to communicate directlywith the user profile (124). The friend profile (126) may still haveaccess to other information associated with the user profile (124), butmay be restricted from adding text, video or pictures to the userprofile (124) or from sending non-public communication to the userprofile (124) within the social network (114). The social network (114)may also allow “friend of a friend” communication, whereby even if onefriend profile (126) is not directly authorized to communicate withanother friend profile (128), if the friend profile (126) is authorizedto connect to other friend profiles which are authorized to directlycommunicate with the friend profile (128), the friend profile (126) isthereby authorized, through this string of authorizations, tocommunicate directly with the friend profile (128).

While the term “friend” is used to describe connection between profilesin the social network (114), there is no requirement that the connectedprofiles be associated with people or entities who are actually friendsor who have ever communicated outside of the social network (114). Theterm “friend” is merely used to describe the existence of connectionsbetween profiles in the social network (114) authorized by the partiesinvolved.

FIG. 2 is a block diagram of a social network server (130) associatedwith the social network (114). As used herein, the term “website” meansany system providing content and is not limited to those systemssupporting content provided via the Internet or the http protocol. Ingeneral functions described herein as being performed on the server sidemay also be performed on the client side as appropriate. The socialnetwork server (130) has a web server (132), an action logger (134), anapplication programming interface (API) request server (136), an actionlog (138), a feed generator (140), a member profile database (142) and aconnection database (144). The social network (114) and social networkserver (130) may include more or less features, or may includemodifications of the features described herein. Conventional features,such as firewalls, load balancers, application servers, fail overservers, site management tools, as well as additional conventional knownfeatures are not shown to allow a clearer illustration of the novelfeatures of the system.

The social network server (130) allows a user (102) to create the userprofile (124). The user profile (124) may include information about theuser (102), such as biographic information, user posted text,hyperlinks, photos or video and statistics regarding the user's use ofthe social network (114). The biographic information may include workexperience, education, physical description, likes, dislikes, hobbies,preferences, geographic location and similar information. The socialnetwork server (130) also stores information regarding the connections(118) associated with the user profile (124). To make a connection witha friend profile (128), the user (102) accesses the friend profile (128)using the user profile (124) of the social network (114). While thefriend profile (128) may be completely or partially visible, there willbe a designated process to request a connection, such as a button orhyperlink. On pressing the button, the user's request for connection ispassed along to the owner of the friend profile (128). In some socialnetworks (114), the social network (114) allows the user (102) to viewthe complete friend profile (128) upon requesting the connection. Inother social networks (114), the social network (114) does not allowviewing of the friend profile (128) until the owner of the friendprofile (128) accepts the connection request, in which case the socialnetwork (114) stores the connection between the user profile (124) andfriend profile (128) in the connection database (144). Most socialnetworks also provide a process to allow a user to block access to theuser profile by other selected members of the social network.

In still other social networks (114), the social network (114) allowsthe user profile (124) access to viewing the friend profile (128) uponthe request for connection, but does not allow the user profile (124)direct communication rights with the friend profile (128) unless theowner of the friend profile (128) accepts the connection request. Stillother social networks (114) allow the user profile (124) to view thecomplete friend profile (128), but may only authorize directcommunication from the friend profile (128) to the user profile (124),and withhold direct communication authorization from the user profile(124) to the friend profile (128) until the owner of the friend profile(128) accepts the connection request from the user profile (124).

The recipient (106) accesses the network (108) and social network (130)in a similar manner using a client device (146) and creates a recipientprofile (148) in a manner such as that described above. Thereafter, theuser (102) may send a connection request to the social network (114) tothe recipient (106) through the recipient profile (148). Once therecipient (106) accepts the connection request, the social network (114)stores the connection in the connection database (144).

In addition to serving webpages to the user (102) and recipient (106)via the social network server (130), the social network (114) may serveother web related content, such as Flash, Java, XML and similar content.The web server (132) is provided with a message server (150) to allowmessages to be transmitted between the profiles (124), (126), (128) and(148) associated with the social network (114). The messages may be inthe form of email, chat, text, SMS, or any desired messaging formatknown in the art.

In an exemplary embodiment, the API request server (136) may correspondto one or more dynamic link libraries (DLL) or other libraries thatcomprise standardized functions for communicating with the web server(132). The API request server (136) allows servers (152) associated withexternal websites (154) to access information associated with the socialnetwork server (130) by calling APIs (156) and to execute operations onthe social network server (130), such as sending messages to othermember profiles, by calling other APIs (158). The external websites(154) may be any websites operating from a server other than the serveroperating the social network (114). When it is desired to receiveinformation from the social network server (130), such as informationrelating to the user profile (124), the external system (154) sends anAPI request to the social network server (130) via the network (108).The API request server (136) receives the API request and calls theappropriate API (156) to determine if the external system (154) isauthorized to obtain the requested information, to gather the requestedinformation which is authorized to be provided to the external system(154) and to return the authorized information back to the externalsystem (154) via the network (108).

When it is desired to cause the social network server (130) to performan action, the external system (154) sends an API request to the socialnetwork server (130). The API request server (136) calls the appropriateAPI (158) to determine if the operation is authorized for the externalsystem (154) and, if so, causes the operation to be executed on thesocial network (130). Depending on the request, the API request server(136) may call another API (156) to return information to the externalsystem (154) indicating that the operation has been completed or denied.

The action logger (134) monitors actions by the user (102) and recipient(106) associated with the social network (114), whether such actionstake place on their respective profiles (124) and (148), elsewhere onthe social network server (130) or, if authorized, other places outsideof the social network server (130). All actions of the user (102) andthe recipient (106) monitored by the action logger (134) are recordedand stored in the action log (138) or other database. Types of actionsthat may be recorded and stored include, but are not limited to,requesting connections between members, authorizing connections betweenmembers, sending messages between members, opening messages betweenmembers, suggesting connections, viewing content on other member'sprofiles, requesting, announcing or RSVPing to events.

The feed generator (140) displays “posts” (160) in reverse chronologicalorder on the user profile (124). The posts may be other member'scomments, notices of upcoming events or feeds from third partyorganizations, such as news outlets. The feed generator (140) may bemodified by the user (102) to customize the posts (160) the feedgenerator (140) displays on the user profile (124). The social networkserver (130) is also provided with a privacy server (162) that restrictsaccess to information stored on the social network server (130),including information stored in the action log (138). The user (102) maybe allowed to modify settings associated with the privacy server (162)via the user profile (124) to determine how information related to theuser (102) is stored and shared on the social network server (130). Theuser (102) may authorize the social network server (130) to shareinformation about the user (102) only with specifically authorizedmembers (116) associated with social network server (130) with varioussoftware applications, external systems or any system seeking access tothe information. The information stored by the user (102) on the socialnetwork server (130) may include text, photographs, audio recordings,video, including contact lists and connections formed by the user (102)through the social network server (130).

In an embodiment, the external system (154) is a financial transactionprocessing system shown generally as (164) in FIG. 3. An embodiment of afinancial transaction processing system which may be adapted to thepresent system (100) is described in U.S. patent application Ser. No.12/658,278, which is incorporated hereby by reference.

When the user (102) desires to open an account (166) with the financialtransaction processing system (164), the user (102) accesses, via thenetwork (108), a server (168) associated the financial transactionprocessing system (164), and provides identifying information, such asuser name and password, to create a user account (166).

Alternatively, the user (102) may provide the informationtelephonically, via electronic mail, facsimile or any suitable method ofcommunication. When it is desired to place funds (104) into the useraccount (166), the user (102) accesses a portion of the server (168)protected by secure socket layer (SSL) transmission or similar securityprotocol. The user (102) then transfers funds into the user account(106) by any known means, including but not limited to check, creditcard, debit card, gift card, pre-paid card, other ACH processing,physically delivered cash deposit or any known system of deposit. Theuser (102) may also receive funds into the account (166) from anotheruser of the financial transaction processing system (164) via directdeposit through the server (168).

To deposit funds into the user account (166) from an external financialinstitution (172), such as a bank or credit union, holding funds of theuser (102), the user (102) accesses a user account (170) associated witha financial institution (172) in a manner such as that known in the art.The user (102) then instructs the financial institution (172) viaelectronic correspondence, telephonically or by other known manner, totransfer a first predetermined amount of funds (174) through the network(108) to the user account (166) associated with the financialtransaction processing system (164).

To transmit a second predetermined amount of funds (104) from the user(102) to the recipient (106), the user (102) preferably has anauthorized connection with the recipient (106) within the social network(114). If the user (102) does not already have an existing authorizedconnection with the recipient (106), the user (102) logs into the socialnetwork server (130) and sends, through the user profile (124) or byother known means, a request to connect (118) to the recipient (106)through the recipient profile (148). The recipient (106) accepts theconnection and the connection is stored in the action logger (134).

To transmit the funds (104) to the recipient (106), the user (102)accesses the server (168) associated with the financial transactionprocessing system (164), and logs into the system (164) through a serverinterface such as the homepage (264), shown generally in FIG. 4, usingthe user's email address and password or other known authorizationprocess.

Once the user has logged into the system (164), the system (164)displays the user webpage (176). (FIG. 5). The user webpage (176)displays a sidebar menu (178) listing “send money” as an option andprovides a send money button (180) to display the send money webpage(182). When the user (102) selects the send money button (180), thesystem (164) displays the send money webpage (182), shown generally as(182) in FIG. 6. The send money webpage (182) displays the user name(184), the account number (186), the user's balance (188), as well asother identifying information (190) about the account (166).

The send money webpage (182) also displays fields (192) to be filled inby the user (102), such as a pin number field (194), a send to field(196) an amount field (198), a source field (200), a payment type field(202), an assumption of cost checkbox (204) and a details field (206).The user (102) fills in these fields (192) with the user's pin number(208), the name (210) of the recipient (106), the source (212) fromwhich the transfer funds (214) are to come, the payment type (216), acheck (218) if desired in the check box (204) and a description (220) ofdetails relating to the transaction. As shown in FIG. 6, when the user(102) begins typing the recipient name (210) in the send to field (196),the system (164) drops down a menu (222) of potential recipientscorresponding to the characters typed.

To propagate the drop-down menu (222), the financial transactionprocessing system (164) cross-references a contact list (224) stored inthe profile database (142) of the social network server (130) associatedwith the user profile (124). Alternatively, the user may access thefinancial transaction processing system (164) through an intermediateserver. The intermediate server may cache information received from thefinancial transaction processing system, such as the contact list (224).After the contact list (224) has been cached, the intermediate servermay propagate the menu (222) of potential recipients directly, ratherthan accessing the financial transaction processing system (164) for theinformation. When the system (164) seeks to access the contact list(224) for the first time, if the user (102) is already logged into thesocial network (114), the social network server (130) generates anddisplays to the user (102) an authorization webpage (225) as shown inFIG. 7. Alternatively, the authorization may be executed via OpenAuthorization (OAuth) or any known authorization system. Authorizing thesystem (164) to access the social network server (130), allows thefinancial transaction processing system (164) to retrieve informationfrom the social network server (130) using the API calls (156) and(158). This authorization may be executed the first time the user (102)receives funds through the financial transaction processing system (164)or creates an account (166) within the system (164).

Alternatively, the user (102) may execute the authorization during thefund transfer process. If the user (102) is not already logged into thesocial network (114), the social network server (130) may display anauthorization website where the user (102) is prompted to enter a username and password associated with the social network (114) and select anauthorization button. Alternatively, the user (102) may select thecontact list button (228) from the sidebar menu (178) and select an addsocial network option which allows the user (102) to authorizeadditional social networks in a manner such as that described above.

Once the authorization has been completed, the user (102) is returned tothe send money webpage (182) associated with the system (164). Thefinancial transaction processing system (164) sends an API request forthe contact list (224) through the network (108) to the social networkserver (130). The API request server (136) associated with the socialnetwork server (130) processes the request from the financialtransaction processing system (164) by calling the API (156) to confirmthe financial transaction processing system (164) is authorized toobtain the contact information, collect the contact list (224)associated with the user (102) and return that information to thefinancial transaction processing system (164) via the network (108). Thefinancial transaction processing system (164) may store the user'scontact list (224) in a database (230), or may submit an API request tothe social network (114) each time information from the contact list(224) is needed.

As shown in FIG. 6, as the user (102) types the recipient name (210)into the send to field (196), the financial transaction processingsystem (164) displays associated contacts (232) on the drop-down menu(222). As the user (102) continues to type, the financial transactionprocessing system (164) eliminates non-matching contacts (232) from thedrop-down menu (222). If desired, the user (102) may stop typing at anypoint and select the desired recipient (106) from the drop-down menu(222), thereby causing the system (164) to auto-complete the send tofield (196) with the recipient name (210).

As noted in FIG. 6, the name (210) may be the recipient's actual name, anickname, a street name, user name or standardized format name, such asa user name provided by the “@” or other naming protocol utilized by aspecific social network. Once the user (102) has completed the fields(192), the user (102) selects the next step button (234), causing thesystem (164) to display the confirmation page (236) shown in FIG. 8. Ifthe user (102) notices a mistake in the information regarding theproposed transfer, the user (102) selects the previous button (238)causing the system (164) to return the user webpage (176) with thepreviously completed fields (192). This allows the user (102) to makechanges as required. If the information displayed on the confirmationpage (236) is correct, the user (102) selects the finish button (240),which causes the system (164) to display the detail page (242) shown inFIG. 9. The detail page (242) includes a history (244) of previoustransactions, including the destination (246), the date (248) and theamount (250). The detail page (242) also includes additional tabs (252)to allow the user (102) to review information regarding funds received,funds sent, pending transactions, requests for funds and associatedfees.

Upon execution of the transfer, the system (164) debits the user'saccount (170) by the amount of the transfer and creates a recipientaccount (274) using information obtained from the user (102), includingthe recipient's user name associated with the social network (108). Thesystem (164) credits the recipient account (274) with the amount of thetransfer. The system (164) may charge a fee, which may be extracted fromeither the user account (170) or from funds transferred into therecipient account (274) as indicated by the user (102). If the recipient(106) already has an account created with the system (164), the systemdebits the user account (170), credits the recipient account (274), anddebits the selected account for the amount of the transaction fee.

Once the user (102) selects the finish button (240) on the confirmationpage (236), the system sends an API request to the social network (114).The API request server (236) receives the request and calls theappropriate API (158) to determine if the financial transactionprocessing system (164) is authorized to access the social network (114)via the user profile (124). If the authorization is confirmed, the API(158) sends a message (254) to the recipient profile (148). Preferably,the message (254) is indicated as having originated from the userprofile (124). The message (254) may be private for the recipient (106),displayed as a post on the recipient profile (148) or public accessibleas desired.

When the recipient (106) accesses a message page (258) associated withthe recipient profile (148) of the social network (114), the socialnetwork server (130) displays the message (256), along with information(260) regarding the transaction. (FIGS. 1-3 and 10). The message (256)also includes a hyperlink (262) to the server (168) associated with thefinancial transaction processing system (164).

When it is desired to retrieve the funds (174), the recipient (106) maygo directly to the financial transaction processing system (164).Preferably, the recipient (106) selects the hyperlink (262) associatedwith the message (256). Selecting the hyperlink (262) causes the clientdevice (110) to display the homepage (264), including email and passwordfields (266) and (268), and a social network authorization button (270).(FIGS. 1-4).

Once the recipient (106) has selected the hyperlink (262) in the message(256), the financial transaction processing system (164) displays forthe recipient (106) the homepage (264) displaying the proper socialnetwork authorization button (270) associated with the hyperlink (262).If the recipient (106) has an existing account with the system (164),the recipient (106) fills in the appropriate email address and usernamein the fields (266) and (268), and selects the submit button (272),thereby allowing the recipient (106) access to the recipient's account(274). If the recipient (106) has not previously created an account withthe financial transaction processing system (164), the recipient (106)selects the social network authorization button (270). This causes thesystem (164) to send an API request to the social network server (130)via the network (108). The social network server (130) generates anddisplays to the recipient (106) the authorization webpage (225) that therecipient (106) authorizes in a manner such as that described above.

The system (164) displays a recipient's account page (276) showing thebalance (278) and a record of the transaction (280). The recipient (106)may keep the funds (174) in the system (164), transfer the funds (174)to another user of the system (164), transfer the funds to therecipient's financial institution (282), transfer the funds to a vendor(284) set up to receive funds from the financial transaction processingsystem (164), obtain the funds (174) in the form of a check or debitcard, or transfer the funds (174) in any manner known in the art. (FIGS.1-3 and 11).

As soon as the financial transaction processing system (164) displaysthe recipient's account page (276), the recipient (106) is allowed toaccess the funds (174) and review the account (274) in a manner such asthat described above. The recipient (106) may also select the contactlist button (285) from the sidebar menu (178) to add additional socialnetworks and contacts in a manner such as that described above.

If the user (102) desires to request funds (104), the user (102) logsinto the server (168) of the financial transaction processing system(164) and from the sidebar menu (178) selects the request money button(286). (FIGS. 1-3, 5 and 13). In response, the system (164) displays therequest money webpage (288) with various fields (290) to be filled in amanner such as that described above. As the user (102) fills in therequest funds field (292) the system (164) either accesses the contactlist (224) from the database (230) or sends an API request to the socialnetwork server (130). The API request server (136) confirmsauthorization of the request and returns the contact information to thesystem (164) in a manner such as that described above. The system (164)then lists associated contacts (294) in a drop-down menu (296). The user(102) may either continue filling in the request form field (292) orselect the desired benefactor (298) from the drop-down menu (296).

The system (164) may also autofill the name of the benefactor (298) intothe request from field (292) if the information provided into the field(292) by the user (102) matches a single contact. Once the user (102)has filled out the fields (290) appropriately, the user (102) selectsthe next step button (300) and confirms the request on a subsequentconfirmation page, in a manner such as that described above. Uponselection of the next step button (300) by the user (102), the system(164) sends an API request to the social network server (130) where theAPI request server (136) calls the appropriate API (158) to confirm thatthe user (102) and benefactor (298) are “friends” or are otherwiseconnected. Upon confirmation of the connection, the API (158) sends amessage (304) to the benefactor's profile (302), preferably with anindication that the message (304) was posted through the user profile(124).

When the benefactor (298) logs into the social network server (130) andrequests messages from the website (130), the server (132) displays thebenefactor's message page (306) which lists the message (306) whichcontains a hyperlink (308) and explanatory information (310), such astext, describing the user's request. If the benefactor (298) wishes toprovide funds (312) to the user (102), the benefactor (298) selects thehyperlink (308) causing the financial transaction processing system(164) to display the financial transaction processing system server(168) on the benefactor's client device (314)

As noted above, if the benefactor (298) has already created an accountwith the system (164), the benefactor (298) merely provides the username and password into the appropriate fields and submits them to thesystem (164). If the benefactor (298) has not already created an accountwith the system (164), the benefactor (298) may select the socialnetwork authorization button (270) that sends an API request to thesocial network (114) to confirm the benefactor's identity andauthorization to access the server (168) to provide funds to the user(102). Upon confirmation of the benefactor's authorization to access theserver (168), the system (164) displays a benefactor's funds requestwebpage (318), listing the benefactor's name (320), account number(322), balance (324) and transaction history (326).

If the benefactor (318) does not wish to honor the fund request, thebenefactor (318) may select the cancel request link (328), which removesthe active request (330) from the benefactor's active request listings.If the benefactor (318) does wish to honor the fund request, thebenefactor (318) selects the pay this request link (330), which causesthe system (164) to display the send money webpage (332). (FIG. 16). Ifthe benefactor (318) does not have a benefactor account (336) associatedwith the system (164), the benefactor (318) creates an accountassociated with the system in a manner described above, which willprovide the benefactor with a benefactor pin number (338).

If the benefactor (318) does not have sufficient funds (336) in thebenefactor account (336) associated with the system (164), thebenefactor (318) may create a transfer funds into the benefactor account(336) by any known means, including but not limited to check, creditcard, debit card, other ACH processing, gift card or physicallydelivered cash deposit. The benefactor (318) may also deposit funds intothe benefactor account (336), in a manner such as that described above,from an external financial institution, which may be the same ordifferent than the recipient's financial institution (282).

Once the benefactor (318) has sufficient funds (334) in the benefactoraccount (336) associated with the system (164), the benefactor (318)fills in the pin number field (340), the send to field (342) and anamount field (344). The system (164) may be configured to autofill inthe amount field (344) with the amount (346) of funds requested by theuser (102). The benefactor (318) also fills in a source field (348), apayment type field (350), an assumption of cost checkbox (352) and adetails field (354).

Once the benefactor (318) has completed the fields (192), the user (102)selects the next step button (356). The benefactor (318) may thenconfirm the transfer in a manner such as that described above. Uponexecution of the transfer, the system (164) debits the benefactoraccount (336) by the amount of the transfer and credits the user account(166) by the amount of the transfer. The system may also extract atransfer fee as described above.

Although the invention has been described with respect to a preferredembodiment thereof, it is to be understood that it is not to be solimited since changes and modifications can be made therein which arewithin the full, intended scope of this invention as defined by theappended claims.

1. A computer implemented method for providing transfer of funds from auser to a recipient, the method comprising: (a) providing a socialnetwork; (b) providing a financial network external to the socialnetwork; (c) providing the financial network access to the socialnetwork across a global computer network; (d) creating a user account;(e) associating the user account with the external system; (f) fundingthe user account with a first predetermined amount of funds; (g)creating a recipient account; (h) associating the recipient account withthe external system; (i) creating a user profile; (j) associating theuser profile with the social network; (k) creating a recipient profile;(l) associating the recipient profile with the social network; (m)authorizing the user profile to post messages to the recipient profile;(n) authorizing the transfer of a second predetermined amount of fundsfrom the user account to the recipient account; (o) transferring thesecond predetermined amount of funds from the user account to therecipient account; (p) initiating a message from the external system,wherein the message comprises information associated with the transfer;and (q) displaying the message on a user interface associated with therecipient profile.
 2. The computer implemented method of claim 18,wherein the external system is associated with a financial institution.3. The computer implemented method of claim 18, further comprisingprogramming interface with the social network sending the message fromthe financial network to the social network via the applicationprogramming the interface.